home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 8240 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.5 KB
  1. Path: solon.com!not-for-mail
  2. From: seebs@solutions.solon.com (Peter Seebach)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Type casting
  5. Date: 2 Mar 1996 10:40:50 -0600
  6. Organization: Usenet Fact Police (Undercover)
  7. Message-ID: <4h9tmi$hmq@solutions.solon.com>
  8. References: <4gfnmi$gsc@calvin.risq.qc.ca> <4h5amm$dpv@umbc9.umbc.edu> <4h7oktINN433@anvil.ugrad.cs.ubc.ca>
  9. NNTP-Posting-Host: solutions.solon.com
  10.  
  11. In article <4h7oktINN433@anvil.ugrad.cs.ubc.ca>,
  12. Kazimir Kylheku <c2a192@ugrad.cs.ubc.ca> wrote:
  13. >The reason is a few sentences early in the ISO standard which say that main()
  14. >shall be declared such and such, as I was surprised to find!
  15.  
  16. No, they say it *may* be declared such and such.
  17.  
  18. >Any further justifications may be informative, but are actually superfluous.
  19. >If the assertion were removed from the standard, it would be legal to declare
  20. >main() any way you like, and the conforming environment would have to make
  21. >sure to call it with a compatible sequence no matter how you define this.
  22.  
  23. This is incorrect.
  24.  
  25. No assertion exists in the standard that main may not be declared other ways.
  26.  
  27. Actually, the key is 3.16, which states that it is undefined behavior
  28. whenever anything is done that is not explicitly defined.
  29.  
  30. >However, main()
  31. >is not called from an expression within the C program, so this rule doesn't
  32. >apply to it.
  33.  
  34. You certainly could call it, in which case, your calls would be required
  35. to match your definition.
  36.  
  37. >You are required to write main() a certain way if you expect to write standard
  38. >C, and that is all there is to it. There is no necessary reason why it _has_
  39. >to be that way.
  40.  
  41. No, but a strong logical one - modern OS's (even including DOS, for once)
  42. have a concept of whether a program has succeeded or failed.
  43.  
  44. >Incidentally, the only specific reference to undefined behavior in the context
  45. >of main() that I have been able to dig up in the Standard says that the exit
  46. >status of a program which doesn't provide a return value on exit from main()
  47. >is undefined. There is no discussion over T main() where T is not int,
  48. >versus int main().
  49.  
  50. This is because there's no need for it.  There's also no discussion of what
  51. stdin->_cnt does.
  52.  
  53. 3.16 renders all such behavior undefined, and therefore a bad idea.
  54.  
  55. -s
  56. -- 
  57. Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
  58. C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
  59. FUCK the communications decency act.  Goddamned government.  [literally.]
  60. The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html
  61.